%\paragraph*{Filtro por ruido con SoX:} Se podría analizar mejor los audios si se le aplicara algún filtro que extraiga el ruido. De esta forma se podría mejorar los atributos acústicos. 

%\paragraph*{Chequeador cruzado con grabación:} Que no se muestre la frase a decir, sino que se escuche un audio y se tenga repetirlo. Este audio es el de un hablante anterior pero que se le aplicó un filtro para evitar exponer su acento. De esta forma, chequeamos que se diga lo que se quiere decir y nos aseguramos espontaneidad.

\paragraph*{Chequeador cruzado:} Una mejora, por parte del análisis de datos, podría ser que las grabaciones sean chequeadas entre los hablantes. Un hablante, intercalado con las grabaciones que realiza, podría escuchar un audio y su frase asociada de otro hablante que previamente realizó el experimento. Luego de escucharla, debería decidir si en la grabación se escucha correctamente la frase en cuestión. Si es así, se podría decidir que esa grabación es buena para el extractor y que se mantiene como conservada.

Si se logra que cada hablante pueda chequear que otra frase se dijo correctamente, permitiría que no sea necesario por parte de los administradores del sistema realizar este trabajo. De esta forma, se simplificaría mejor la recolección de grabaciones y su filtrado si están mal grabados.

\paragraph*{Validación de calidad de sonido:} En el momento de grabación, se podría analizar el audio grabado y rechazarlo si no supera un nivel aceptable auditivo. Esto puede implementarse de varias formas. Una posibilidad sería cuando se está grabando medir el volumen del micrófono cada cierta cantidad de tiempo (por ejemplo: 1 segundo). Si en esa medición el volumen no se encuentra entre un rango máximo y mínimo de volumen, descartar la grabación y pedirle al hablante que vuelva a grabar.

También se le podría dar más información al hablante. Sabiendo que el micrófono tuvo un pico de volumen, se podría pedir al hablante que baje el nivel de voz o se aleje del micrófono. Ídem si habla muy bajo. Otras posibles soluciones a este problema son analizar antes de empezar el experimento. Si el ruido ambiente genera saturación, pedir al usuario que realice el experimento en un lugar más silencioso. 

Podemos realizar análisis más precisos sobre la calidad del audio cuando llega la grabación al servidor. En ese momento, el servidor ya puede obtener el archivo wav y realizarle todo tipo de análisis (por ejemplo: detección de ruido ambiente). Recordemos que el servidor esta implementado en Python, que posee muchas bibliotecas útiles para realizar esto. Al momento de terminar de procesar el audio en cuestión, deberá enviar la respuesta al hablante informándole si se debe realizar de vuelta la grabación o si fue exitosa. Es importante notar que esta solución necesita buena conexión al servidor. 

\paragraph*{Puntaje en alineaciones:} En el informe analizamos manualmente si cada grabación fue alineada correctamente. Esto se pudo lograr gracias a que eran pocos audios. En un sistema automático que recolecte grabaciones y además extraiga cada atributo para luego entrenar los clasificadores, esta tarea no se podría realizar.     

Una vez terminada una alineación, ProsodyLab-Aligner genera un archivo donde muestra cómo fueron esas alineaciones. Este archivo se llama \textit{`.SCORES’} y en él se encuentra una lista de todos los audios seguidos de un puntaje. Si una alineación fue similar a otra va a tener aproximadamente un valor similar. En cambio, si posee una alineación muy distinta va a tener valores distintos. Este puede ser un buen filtro para saber si se pudo alinear bien.

Se podría definir un umbral para filtrar cuándo se realizó una alineación correcta. Si esta alineación no supera ese umbral, se debería descartar ese audio. Una cuestión importante a tener en cuenta es la cantidad de falsos positivos que pueden surgir. O sea, la cantidad de audios que no pasan el umbral pero están bien alineados.   

\paragraph*{Clasificación en vivo:} Se podría realizar una prueba online de clasificación de hablantes. La misma consiste en realizar el mismo experimento para un hablante y que al final le devuelva como resultado si pertenece a Buenos Aires o Córdoba.

Esta clasificación en vivo necesitaría de los trabajos futuros relacionados con automatización del sistema. Cada vez que se realice el experimento para un hablante nuevo, se deberá recalcular el clasificador. De esta forma, se le puede dar una respuesta sobre a qué grupo pertenece.

\paragraph*{Mejores modelos y atributos:} Se podría analizar si existen más y mejores atributos que distingan estos dos grupos. Por ejemplo: se podría analizar si la sílaba anterior a la sílaba acentuada se sigue estirando cuando éstas están en palabras distintas.

También se pueden mejorar los modelos de test incluyendo variantes que analicen de distinta forma los atributos desconocidos. Otro análisis interesante sería cómo mejorar el rendimiento de cada clasificador variando sus parámetros.